fix(plugin-tree): re-key ObjectTree's record-fetch effect onto dataConfig primitives (#6700) - #6701

Fixes #6700

What

packages/plugin-tree/src/ObjectTree.tsx's record-fetch effect closed over
dataConfig — a useMemo over the schema prop — as a dependency, instead
of the primitive fields it actually reads off it. This is the last
dataConfig-identity dependence left in the component: #6696 already
re-keyed the schema-resolution half onto useSettledSchema's primitive
schemaKey, so this PR closes out the component (not just one effect),
completing the #6592 census for ObjectTree.

Re-derived read set

Scanning the effect body directly (not the issue's suggested list, which
conflated this effect with an unrelated headerObjectName read at
ObjectTree.tsx:503-504 outside this effect) — three primitives:

• dataConfig?.provider — gates both the 'object' and 'value' branches.
• dataConfig.object — read only inside the provider === 'object' branch.
• dataConfig.items — read only inside the provider === 'value' branch.

Before / after deps

- }, [dataConfig, dataSource, schema.filter, objectSchema, schemaSettled, (rest as any).data]);
+ }, [dataProvider, dataObjectName, dataItems, dataSource, schema.filter, objectSchema, schemaSettled, (rest as any).data]);

with the three derived right after the useSettledSchema call:

const dataProvider = dataConfig?.provider;
const dataObjectName = dataConfig?.provider === 'object' ? dataConfig.object : undefined;
const dataItems = dataConfig?.provider === 'value' ? dataConfig.items : undefined;

Mirrors the pattern already shipped for ObjectMap/ObjectCalendar/
ObjectGantt (objectui#6592) — same naming, same shape.

Discard-pin demonstration (ObjectTree.discardedConfigMemo.test.tsx)

Trigger: two schema object literals with identical primitive content but
different references, rerendered in place. ObjectTree's own dataConfig
memo is useMemo(() => getDataConfig(schema), [schema]) — keyed on the
whole schema object — so a reference swap reliably forces a recompute,
which is the same "different identity, same content" observable a genuine
useMemo cache discard would produce with schema held constant.
useSettledSchema's own internal effect is keyed on the derived primitive
schemaKey string (not schema/dataConfig), so this swap leaves
objectSchema/schemaSettled referentially stable and can't confound the
result through that channel.

RED-pre-fix proof (mutation leg of the ablation below): reverted
ObjectTree.tsx to the pre-fix origin/main content, kept the new pin,
rebuilt, and ran it —

AssertionError: expected 2 to be 1 // Object.is equality
- 1
+ 2
 ❯ ObjectTree.discardedConfigMemo.test.tsx:77:47
 Test Files  1 failed (1)
      Tests  1 failed | 1 passed (2)

The discard-proxy test failed (an extra dataSource.find call fired on the
schema-reference swap); the "still refetches for a genuinely different
object" counter-probe passed either way, as expected — that behavior
predates this fix.

Ablation — predicted vs. observed

Restoration proven byte-identical: git diff HEAD empty, git hash-object
match (94ba6dce7… both before and after the mutation leg). Mutation
landing on disk proven by anchored grep -c on the pre-fix deps-array
marker (dataConfig, dataSource, schema.filter → 1 hit) and the post-fix
primitive marker (dataProvider → 0 hits) before rebuilding.

Both legs matched prediction (no direction surprise, unlike #6592's
ObjectCalendar trigger — verified this component's actual [schema]-keyed
memo forces the recompute before trusting the trigger).

Gate table

All commands run from the repo root, exit captured by redirect-then-capture
(never after a pipe), at final commit ee86dc339:

Changeset: patch on @object-ui/plugin-tree, per check:changeset-presence's own verdict.

Fence

packages/plugin-tree only. Did not touch packages/types, app-shell,
plugin-designer (#6527), packages/react/src/utils/visibilityDiagnostic.ts
(#6504), or packages/react's useSettledSchema hook (consumed as-is).

Generated by Claude Code